1. Technical Field
The present invention relates in general to a method and system for improved data processing and in particular to an improved method and system for linking object files to construct an executable file. Still more particularly, the present invention relates to an improved method and system for constructing a compact executable file by eliminating redundant debugging strings.
2. Description of the Related Art
When developing software, a programmer commonly utilizes a debugger to troubleshoot the program under design. A debugger is a program which enables the programmer to interactively step through an executable program one statement at a time, examining variable values, checking conditions, and setting break points. In order to utilize a debugger, the programmer compiles the source code of the program to be analyzed utilizing a compiler option that inserts debugging information into the resultant object files. The debugging information inserted into the object files enables the debugger to identify variable types utilized within the object files, thereby ensuring that the debugger correctly interprets variable formats within memory.
Referring now to FIG. 4, there is depicted the conceptual format of an object file utilized by the AIX operating system, the IBM version of UNIX. As illustrated, object file 70, like similar object files employed by other operating systems, comprises one or more headers 72 followed by program data sections 74, symbol table 78, and string table 82. Symbol table 78 includes a number of fixed-length entries 80 containing either linking symbols or debugging symbols. Linking symbols are required by the linker to resolve symbols when creating an executable program by linking object file 70 with other object files. Unlike linking symbols, debugging symbols, which are utilized by the debugger to ascertain the types and memory locations of variables, are generated only if the object file is compiled with a debugging option enabled. Because symbol table 80 stores only fixed-length information, if a symbol within an entry 80 describes variable-length information, the information associated with the symbol is placed in .debug section 76 if the symbol is a debugging symbol and in string table 82 if the symbol is a linking symbol. Entries 80 that refer to .debug section 76 or string table 82 contain an integer offset specifying the location of the variable-length information with respect to the beginning of its respective section.
The variable-length information associated with a particular entry 80 is stored within .debug section 76 as a character string called a stabstring (Symbol TABle STRING). Variable types utilized within object file 70 are specified within stabstrings by type numbers. Some variable types, such as integer, are predefined and are consistently specified within all object files utilizing unique negative type numbers (i.e., negative integers). Other variable types, however, which are defined with reference to predefined types or other defined types, are specified with arbitrary positive integers that can differ between object files. Thus, type 2 in one object file may or may not be of the same variable type as type 2 in another object file. Stabstrings can have one of two basic formats. A first variety of stabstrings defines a variable type by writing an integer followed by an equal sign and type definition. For example, the stabstring ":t2=*4" defines type 2 with reference to type 4. The second variety of stabstrings associates a symbol with a variable type. For example, the symbol X is associated with type 3 by the stabstring "X:3." As will be appreciated by those skilled in the art, not all integers appearing in a given stabstring represent variable types. Consequently, a stabstring must be parsed to determine if a particular integer within the stabstring specifies a variable type or merely indicates a length, an offset, or other data related to the associated symbol.
With reference now to FIG. 5, there is illustrated a conceptual view of the construction of executable file 90 from object files 92 and 94 according to a conventional method. As depicted, when object files 92 and 94 are linked, sections .debug A and .debug B within object files 92 and 94, respectively, are simply concatenated to form the .debug section of executable program 90. Thus, during a debugging session of executable program 90, debugging symbols within symbol table A would be defined with reference to stabstrings within .debug A and debugging symbols within symbol table B would be defined with reference to stabstrings within section debug B. Although the conventional method of linking object files 92 and 94 to construct executable program 90 is efficient when only linking time is considered, as the number of object files linked increases, the conventional technique of linking object files results in a large .debug section, and consequently, a large executable program 90. When the size of an executable program becomes large, debugger performance declines concomitantly for two reasons. First, if the executable program is stored on a remote file server, transferring a large executable program from the server to a local node is time consuming. In addition, increasing the size of the executable program increases the time that the debugger requires to read and interpret the stabstrings and can increase the number of memory page faults during execution, thereby decreasing performance.
In order to enhance debugging efficiency, some prior art systems have implemented additional processing while linking object files in order to reduce the size of the .debug section within the resulting executable program. For example, in some prior art system, variable types are specified by an arbitrary type number and a file name. By identifying and eliminating duplicate variable types which reference the same include file, the prior art systems decrease the number of stabstrings within the executable program. However, this technique of reducing the size of executable programs has a shortcoming in that identical variable types declared in different include files cannot be recognized as duplicates.
Consequently, it would be desirable to provide an improved method and system for reducing the size of executable programs by eliminating duplicate stabstrings.